<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>

<HEAD>
	<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
	<META NAME="GENERATOR" Content="Visual Page 1.1a for Windows">
	<TITLE>untitled</TITLE>
</HEAD>

<BODY BGCOLOR="#FFFFFF">

<P><FONT SIZE="5" FACE="Tahoma"><B>Using HTML as a User Interface Mock up Medium</B></FONT></P>
<P><FONT SIZE="2" FACE="Tahoma">Authors: Jaya Vaidyanatha, Jason E. Robbins, David F. Redmiles<BR>
Demonstration done by Jaya and Jason</FONT></P>
<P><FONT SIZE="2" FACE="Tahoma"><BR>
</FONT>
<TABLE BORDER="0" CELLSPACING="1" WIDTH="700">
	<TR>
		<TD WIDTH="10" ROWSPAN="2" BGCOLOR="#C0C0C0"></TD>
		<TD WIDTH="690" BGCOLOR="#C0C0C0"><FONT SIZE="4" FACE="Tahoma"><B>Introduction</B></FONT></TD>
	</TR>
	<TR>
		<TD WIDTH="690">
			<P><FONT SIZE="2" FACE="Tahoma">This web page demostrates a technique to quickly explore user interface alternatives
			using standard HTML authoring tools rather than GUI building tools. Using HTML tools have several advantages in
			early mockups:</FONT></P>
			<UL>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML is a very flexible medium.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">Making early HTML mockups can be very fast.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML tools are widely available and provide many useful features.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">The HTML mockups focus on sequenceing of screens which is hard to do with standard
				GUI builders.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML mockups can evolve directly from requirements documents.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">Early HTML mockups defer commitment on presentation details (e.g., fonts, and
				widget sizes).</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML allows for incremental commitment to different UI design issues (e.g., rough
				content, screen flow, screen presentation, error handling, timing issues).</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML mockups can be placed on the web for convenient evaluation and reference
				by designers and implementers that may be local or remote.</FONT>
				<LI><FONT SIZE="2" FACE="Tahoma">HTML mockups can be &quot;run&quot; in any web browser.</FONT>
			</UL>
		</TD>
	</TR>
	<TR>
		<TD WIDTH="10"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
		<TD WIDTH="690"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
	</TR>
	<TR>
		<TD WIDTH="10" ROWSPAN="2" BGCOLOR="#C0C0C0"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
		<TD WIDTH="690" BGCOLOR="#C0C0C0"><FONT SIZE="4" FACE="Tahoma"><B>Example System: Gas-Cash-Dash</B></FONT></TD>
	</TR>
	<TR>
		<TD WIDTH="690"><FONT SIZE="2" FACE="Tahoma">The example system being designed is point-of-sale system for use at gas stations.
			Many gas stations now use pay-at-the-pump systems that allow customers to buy gas using their credit or debt cards.
			In this demonstration we consider a hypothetical system, named Gas-Cash-Dash, that sells gas, sells lottery tickets,
			redemes some winning tickets, and dispenses cash (like an ATM). <BR>
			<BR>
			Requirements for this system are outlined below. Briefly, the system's basic functionallity should be usable by
			first time customers, the number of steps in the dialog should be kept fairly short, and costomer time should be
			minimized to increase the number of customers served during busy periods. The design also needs to consider some
			security issues, however those are not the focus of this example. <BR>
			<BR>
			We explore the requirements and design of the user interface of the next section.</FONT></TD>
	</TR>
	<TR>
		<TD WIDTH="10">&nbsp;</TD>
		<TD WIDTH="690">&nbsp;</TD>
	</TR>
	<TR>
		<TD WIDTH="10" ROWSPAN="2" BGCOLOR="#C0C0C0"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
		<TD WIDTH="690" BGCOLOR="#C0C0C0"><FONT SIZE="4" COLOR="#000000" FACE="Tahoma"><B>Demonstration of the HTML UI Mock up Techique</B></FONT></TD>
	</TR>
	<TR>
		<TD WIDTH="690">
			<P><FONT SIZE="2" FACE="Tahoma">To demonstrate our technique, we present a series of snap-shots of documents we
			used in mocking up the design. Each successive refinement represents less than 30 minutes of mocking up effort.
			The Notes document contains notes that we made as part of doing the mocking up, the Mockup document contains
			the actual mockup.</FONT></P>
			<P><FONT SIZE="2" FACE="Tahoma">Each document was produced with a standard HTML editor. We used Symantec VisualPage,
			however other editors could certainly be used instead. We have done only minimal clean-up of the documents to remove
			some typos and add a one-line header.</FONT></P>
			<P><FONT SIZE="2" FACE="Tahoma">Documents and versions:</FONT></P>
			<UL>
				<LI><FONT FACE="Tahoma"><B>Step 1: List system functions used in a typical session</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes1.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v1</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					In this step we outlined the hardware on which the system will run, the bsaic required functionality, and issues
					to be decided.</FONT>
					<LI><A HREF="gcd1.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Protoype v1</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					Here we roughly outlined the screen flow for the overall customer session, without regard for issues of screen
					layout, content, presentation, or timing. These main steps were cut-and-pasted directly from an early requirements
					document. Although we are using a full HTML editor, we are mainly composing an unformatted outline.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 2: Refine system function outline to cover multiple typical sessions</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes2.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v2</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					In this step we realized that decisions needed to be made regarding security and the availability of hardware menu
					buttons.</FONT>
					<LI><A HREF="gcd2.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Protoype v2<BR>
					</FONT></A><FONT SIZE="2" FACE="Tahoma">Here we expanded the menu tree to cover more of the required functionality,
					still without much regard to presentation issues. We quickly considered several alternative locations for important
					functions, namely the sale of car washes.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 3: Divide system functions into screens shown in typical sessions</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes3.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v3</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					More information about available hardware buttons and digital price displays is fleshed out as needed. Issues raised
					in experimental postioning of functions are noted.</FONT>
					<LI><A HREF="gcd3.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Protoype v3</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					We quickly divided our user interface outline into screens by using HTML dividers. The one line discription of
					each step in the customer's session is used as an initial title of the screen. We added bracketed terms, e.g. [Card_in],
					to represent events that we expect to happen while each screen is displayed.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 4: Define screen flow by using local HTML links, do first &quot;runs&quot;</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes4.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v4</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					We identified new issues stemming from the frequent need to dip credit or debt cards in our current design.</FONT>
					<LI><A HREF="gcd4.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Protoype v4</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					We added HTML anchors for each screen simply by selecting the title of the screen and pressing a create anchor
					button in the HTMl editor. We added links from the bracketed events to destination screens by a quick drag-and-drop
					operation in the HTML editor. <BR>
					At this point the mockup can be &quot;run&quot; by placing the editor into page preview mode, making the window
					small enough to display only one screen, and clicking on a sequence of links as if we were actually using the system.
					In cases where links have not yet been defined, the UI designer can simply scroll to a different screen.<BR>
					During initially runs of the mockup, we realized the need for more intermediate screens and revised some of
					the phrases presented to the user.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 5: Fill in more details and conditions as desired</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes5.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v5</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					More issues were identified as the mockup was fleshed out more and more screen flow was designed. Notes were
					organized a bit more using HTML outlining.</FONT>
					<LI><A HREF="gcd5.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Protoype v5</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					We filled in more details of the mockup screen flow which identified more issues. We considered which screens
					can time-out and certain errors (e.g., network failure, printer failure, no cash, etc.). Informal evaluation runs
					showed that we needed more confirmation screens.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 6: Address layout issues by using HTML tables</B></FONT>
				<UL>
					<LI><A HREF="gcd_notes6.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Notes v6</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					Identified more issues of related to key assignments and confirmation.</FONT>
					<LI><A HREF="gcd6.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Mockup v6</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					In this step we started to mockup screen layout. We used HTML tables to roughly mock-up the screen and buttons.
					After one table was made, it was cut and pasted for each screen. Existing text and links were dragged and dropped
					into the table cells. At this stage we are still using default HTML fonts, but we get a rough idea of what will
					fit. Events that do not correspond to buttons are still shown in brackets at the bottom of each screen.</FONT>
				</UL>
				<LI><FONT FACE="Tahoma"><B>Step 7: Refine layout issues by using HTML images</B></FONT>
				<UL>
					<LI><FONT SIZE="2" FACE="Tahoma">Notes v7</FONT>
					<LI><A HREF="gcd7.htm" target="example"><FONT SIZE="2" FACE="Tahoma">Mockup v7</FONT></A><FONT SIZE="2" FACE="Tahoma"><BR>
					In this step we made GIF images to mock-up certain screens that had problematic layout or that were key to further
					design and implementation.</FONT>
				</UL>
			</UL>
		</TD>
	</TR>
	<TR>
		<TD WIDTH="10"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
		<TD WIDTH="690"><FONT SIZE="2" FACE="Tahoma">&nbsp;</FONT></TD>
	</TR>
</TABLE>
</P>
<P>

</BODY>

</HTML>